High-speed circuit-switched networks, such as Synchronous Optical Networks/Synchronous Digital Hierarchy (SONET/SDH) and Wavelength Division Multiplexed (WDM) networks, are primarily used to provide physical facility or “wire” service in the current Internet and telephone networks. In other words, SONET or WDM lightpath circuits are used to interconnect IP routers, ATM switches or Time Division Multiplexed (TDM) crossconnects. The data rates of these circuits are so high that their direct use is seldom considered for end-to-end applications; packet-level multiplexing as offered by IP or ATM, or DSO level circuits used by data-generating endpoints. Even video applications, which are expected to have the highest bandwidth requirements, require far less bandwidth than provided is by the least-bandwidth SONET circuit of approximately 51 Mbps.
After considering many alternatives, perhaps the only end-to-end applications that could potentially use direct SONET or WDM lightpath (without any multiplexing on it) circuits are file transfer applications for large files. The high data rates of SONET are not the issue, since the higher the rate, the shorter the file transfer delay. Also not an issue is the drawback of circuit-switched networks at handling bursty traffic with file transfer applications, since there is no intrinsic burstiness in communicating a large file from one computer to another. Once a file transfer starts, bits can be sent continuously with no gaps. Thus, it is desirable to provide the usage of end-to-end high-speed circuits for the actual large file transfers. The related requests-for-files and other supporting communications required by every file-transfer application may use an associated connectionless network, such as an IP network, for support of data transfers. Furthermore, the SONET bandwidth granularity issue is not a problem for a file-transfer application, since a file transfer may occur at any rate and any granularity.
It is known from an analysis in a paper by Miyahara et al entitled “A comparative evaluation of switching methods in computer communication networks,” appearing in Proc. of IEEE, ICC, San Francisco, June 1975, pp. 6–10; that for large file transfers, circuit switched networks provide lower delays and higher throughputs than connectionless packet-switched networks. A similar analysis is known from Schwartz's book Telecommunication networks, by Addison-Wesley Publishing Company, 1988; and also from McDonald's book Fundamentals of digital switching, by Plenum Press, 1983. The reason for such results is that while circuit-switched networks suffer from the overhead of initial call setup, once the circuit is established, per-packet overhead, acknowledgment overhead and queuing delays, are not incurred as they are in packet-switched networks. Additionally, in connectionless networks, packet loss due to buffer overflows may cause congestion control schemes, such as TCP's slow start, to drop data rates, further affecting the total file transfer delay. However, in circuit-switched networks, besides call processing delays, an additional delay is incurred at the start as a call waits for resources to become available if all resources are in use when the call arrives. This is in contrast to connectionless packet-switched networks in which all calls (for example new file transfer sessions) are admitted and packets compete for the network resources. In circuit-switched networks, a call is assigned a dedicated resource for the whole duration of the call and other calls wait in line until resources become available for their file transfers.
In Miyahara et al's paper mentioned above, the delay associated with waiting for resources, which is here after referred to as “call queuing” delay, is characterized as kTwait, where k is the number of the switches on an end-to-end path and Twait is the average waiting time for resources at each switch. In such a scheme, a call setup message is held up at each switch sequentially along an end-to-end path until resources become available at each switch. There are two problems with this simple scheme. First, the total queuing delay incurred waiting for network resources can become rather large due to the sequential waiting period at each switch on the end-to-end path. Second, while call queuing schemes in general improve bandwidth utilization over call blocking schemes, the kTwait scheme will not achieve the improvement that is possible. The reason an improvement in bandwidth utilization can be expected in call queuing schemes is that by having buffers to queue calls, less bandwidth is needed than for a strictly call blocking scheme. The reason why the kTwait scheme does not take advantage of this improvement is that upstream switches hold resources while waiting for downstream switches to admit a call instead of utilizing the wait period to admit shorter calls that only traverse upstream segments.
To overcome these two problems of the simple wait scheme, improvements to the simple call queuing scheme were desired. This led to a queuing scheme where the switches agreed upon a delayed start time for a given call c, and allowed other calls sharing segments of the end-to-end path of call c to use the network resources for other calls before call c started. This decreased call queuing delays and allowed for the utilization gains of call queuing to be realized. However, scheduling calls for a delayed start time with mutual agreement at all the switches on the end-to-end path was only possible if the call holding times were known. A switch cannot guarantee that resources will be available for a new call c at some later point in time if the switch does not know when existing calls will be completed. However, as it turns out, call holding time for large file transfers on circuit-switched networks can be determined a priori if the file sizes, the data rates of the circuit, and propagation delays are either known or can be quickly determined by calculation. Hence, it is desirable to provide an improved call queuing/scheduling problem for calls with known holding times through a network having one or more switches.
Data transfers with known holding times are those that satisfy two properties: (i) the sending end of the data transfer is from a “stored” source rather than a “live” source, and (ii) the network supporting the data transfer uses a preventive congestion control scheme rather than a reactive scheme. Examples include large file transfers on circuit-switched networks and video-on-demand movie transfers on packet-switched connection-oriented networks with preventive congestion control, such as ATM variable bit rate service.
Connection-oriented (CO) networks have been either circuit-switched or packet-switched. In a CO network, connection setup and release procedures, along with the associated message exchanges, constitute the signaling protocol. In circuit-switched telephony networks, the signaling protocols used to set up and release 64 Kbps (DS0) circuits are Q.931, as described in ITU-T, “ISDN user-network interface layer 3 specification for basic call control,” Recommendation Q.931, May 1998; and ISDN user part, as described in ITU-T, “Signalling system no. 7-ISDN user part functional description,” Recommendation Q.761, December 1999. Signaling protocols have also been used in packet-switched connection-oriented networks, such as X.25 and ATM networks. The User Network Interface (UNI) signaling protocol, as described in The ATM Forum Technical Committee, “Uni signaling 4.0,” af-sig-0061.000, July 1996; and Private Network-to-Network Interface (PNNI) signaling protocol, as described in The ATM Forum Technical Committee, “Private network-network specification interface v1.0f (pnni1.0),” af-pnni-0055.000, March 1996; have been used to set up and release virtual circuits in ATM networks. Signaling protocols for IP networks are a more recent development, given that connectionless IP networks have now been augmented with connection-oriented capabilities. Examples include the Resource reSerVation Protocol (RSVP) as described in R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, “Resource reservation protocol (RSVP) version 1 functional specification,” RFC 2205, IETF, September 1997; YESSIR as described in P. Pan and H. Schulzrinne, “YESSIR: A simple reservation mechanism for the internet,” Research Report, RC 20967, IBM, September 1997; Label Distribution Protocol (LDP) as described in L. Anderson, P. Doolan, N. Feldman, A. Fredette, and B. Thomas, “LDP specification,” Internet Draft, IETF, January 1999. and previous other protocols. However, none of these signaling protocols define procedures for setting up connections using knowledge of connection holding time(s).
There are two characteristics that are needed for calls to have known holding times: a sending end of the call should be “stored,” as opposed to “live,” and a connection oriented network should use preventive rather than reactive congestion control.
TABLE IReferring to TABLE I,DESTINATION ENDSENDINGENDLIVESTOREDLIVEInteractive/RecordingLive StreamingSTOREDStored StreamingFile Transfersconsider the first mentioned characteristic. Table I shows that the sending end and destination end of any data transfer can each be “live” or “stored.” If both ends are live and the communication is bidirectional, they are classified as interactive. An example of this category is human telephony, where the call holding time is unknown. Given that both ends are “live” and both ends can send traffic, the call might have a holding time for any length. If both ends are live, but the communication is unidirectional, this case is referred to as a live streaming data transfer. An example is listening to/viewing a live radio/TV broadcast. The next category shown in Table I is recording, where the source is live, but the destination is a stored data device. In both the live streaming and recording categories, the call holding time may or may not be known depending on the duration of the live “event.” For e.g., the duration of coverage of a live parade could be known a priori and advertised by the audio/video distributor; on the other hand, the duration of a sporting event, for e.g., a tennis match, is not known beforehand. Therefore, in general it is assumed that if the sending end is “live,” the call holding time is unknown.
However, if the sending end is “stored,” call holding times are known if the network is used with preventive congestion control (rather than reactive). For e.g., transferring a stored file from a source to a receiver where it is also stored for later consumption (classified as file transfers in Table I) on a TCP/IP network results in an unknown holding time since this network uses reactive congestion control. On the other hand, if the same file is transferred on a circuit established through a circuit-switched network, the holding time can be determined from the file size, the data rate of the circuit, and propagation delays. Similarly, applications in which stored audio or video clips (for e.g., in a web-based class lecture or Video on Demand (VOD)) are consumed live (for e.g., by a student listening) are classified as stored streaming in Table I. If such data is sent on a packet-switched connection oriented network (to take advantage of silences, packet-switched networks are better for this class of applications), and the network supports preventive congestion control, then the call holding time is known. For example, if an ATM Variable Bit Rate (VBR) connection is used rather than an Available Bit Rate (ABR) connection, the call holding time can be predicted given the exact traffic characterization of the stored audio or video file.
Thus, there are a number of applications, which when used on certain types of networks, have deterministic and known call holding times. There is a need in the art to provide methods and systems to make a data call over a connection oriented network when the holding time of the data call is known.